The present invention relates to microprocessor systems and, more particularly, to a system and method for preventing execution of selected implemented instructions on a microprocessor. A major objective of the present invention is to provide for effective utilization of a defectively designed microprocessor.
Much of modern progress is associated with advances in computer performance. Recent computers typically use one or more microprocessors to execute desired operations. Each microprocessor design is characterized by the set of "implemented" instructions it can recognize and execute. The instructions have a respective instruction format.
In many cases, the format can provide for "unimplemented" instructions that the microprocessor is not designed to execute. These unimplemented instructions are of two types: 1) defined but omitted; and 2) undefined (or "reserved"). Many processors are members of processor families that can include more and less sophisticated versions; some instructions that are implemented (and thus defined) on the more sophisticated versions are omitted on the less sophisticated versions. For example, floating-point instructions are defined but omitted on versions of microprocessors with nonfunctional floating-point units (Intel 486SX, Motorola 68LC040). "Undefined" instructions are not defined for any processor, but remain "reserved" for processors yet to be designed.
Microprocessors typically include some means for handling unimplemented instructions. For example, upon detection of an unimplemented instruction in a running application program, a microprocessor can access a software exception handler. The handler can retrieve the unimplemented instruction from memory and determine a suitable course of action. (For example, a floating-point operation can be executed in software if the microprocessor does not have a floating-point unit.) The exception handler can also store as much of the microprocessor's state as necessary for proper restoration before the interrupted application program resumes.
Because they are so widely used, in critical as well as non-critical applications, microprocessor designs are exhaustively tested. However, as integrated circuit density has grown exponentially, so has the number of implemented logic functions. Design testing, using both simulation and prototypes, has also developed to permit more sophisticated confirmation of logic designs. However, the ability to implement functions in an integrated circuit is expanding faster than the ability to test the designs. Accordingly, it has become inevitable that a popular microprocessor would appear with a significant logic design error.
The inevitable became the actual in 1994 when a user identified a design defect in the Pentium processor from Intel Corporation. In some cases, a floating-point divide instruction yielded an erroneous result. As more complex processors are designed, such logic design defects can be expected to recur. Given that they are inevitable, the challenge becomes how to handle them once they are discovered.
Intel tried several approaches to addressing the Pentium defect. The first approach was to keep the defect secret while they worked on a redesign. While economical from a manufacturer's standpoint, this approach has proved unpopular with users that had to discard months of work due to uncertainties in the computations relied upon that arose once the defect was disclosed. The second approach was to offer a limited exchange only for those users who could demonstrate that the defect would affect them. This limited exchange approach was also unpopular because it placed a burden of proof on users, and threatened to leave other good faith purchasers to rely on a processor known to be defective.
A more popular approach was an open exchange of a defective processor with a corrected version of the processor. However, this is potentially a very costly solution as two processors are shipped for the price of one. The economics of the exchange can be much worse where the updated processor turns out to have subsequently discovered defects that require a further exchange.
There are also software-based solutions. For example, a software monitor program can examine an instruction stream in real time to detect for problematic instructions. This approach is problematic because the instructions of the monitor must be executed for each program instruction, exacting a substantial performance penalty even for programs that do not use the problematic instructions. In addition, there is a significant potential for incompatiability with available software.
The performance penalty could be eliminated largely by recompiling programs to eliminate the offending instruction. The recompiling could be done "off-line". Intel provided such a solution involving multiplying dividends and divisors by 15/16. If this recompiling is to be performed by the user, it would be extremely difficult without program source code; in general, a user would not have access to source code for commercially available programs. The software manufacturers could perform the recompiling, but then there is the cost and difficulty of reaching the consumers with the recompiled program. In some cases, recompiling might violate a software license agreement. Moreover, a performance penalty would be suffered (relative to the unrecompiled program) when the processor was upgraded or the program transferred to another computer system with a different but related processor.
What is needed is a better approach to dealing with logic design defects in installed microprocessors. This approach should preserve user expectations for the processor as well as the financial expectations of the manufacturer and distributors. Recompiling should not be required; performance penalties and compatibility problems should be minimized.